Despite the bursting of the dot corn bubble, electronic commerce continues to be an increasingly important aspect of the economy. To the general public, the most visible face is the increasing number of Business-to-Consumer interactions available via the web. However, the majority of economic transactions occur between businesses, making the Business-to-Business (B2B) aspect of electronic commerce a significantly larger market and hence more important area for improvements.
Historically, business relationships have been long-term. When such a relationship has been established, EDI (Electronic Data Interchange) technology can be used to automate certain straightforward interactions between the business partners—for example, the purchase of goods at a pre-agreed price, and the delivery of them. Setting up the EDI system requires the two parties to agree on interaction protocols and message formats, and to implement a messaging system that meets these agreements—often over a Virtual Private Network. This can be a time-consuming and costly process.
RosettaNet (www.rosettanet.org) is an industrial consortium which aims to make this process cheaper and more straightforward, by using XML (extensible Mark-up Language) messaging technology transported over the World Wide Web. It does this by standardising the format, content and sequence of messages between partners for a variety of possible interactions which companies can use in B2B relationships. Hence, companies do not need to go through a lengthy negotiation to specify the way in which they are going to interact. Instead, they simply need to agree on which standard interaction to use. Standardisation also speeds up the development process: products such as WebMethods Trading Networks Server include software libraries and XML templates supporting RosettaNet interactions.
This standardisation effort has substantially reduced the cost and time of setting up a B2B relationship. However, because it is based on XML technology, the tools provided are primarily syntactic, rather than semantic. Semantic constraints on interactions are currently represented informally and require manual interpretation. The standardisation has also necessarily maintained some flexibility to allow companies with different internal processes to comply with the standard.
An overview of RosettaNet together with some of the problems that implementors encounter when they deploy RosettaNet solutions is now described.
RosettaNet standards have gone a long way to ease the process of setting up and executing long-term B2B relationships via the World Wide Web. The key concept used to do this is the Partner Interface Process (PIP). PIPs are used to define standard ways of interacting between companies to carry out a specified task. They define the aspects of a business process which are common to the two parties, but place no constraints on how the internal processes implement these common aspects. A PIP specification defines the flow of message documents which will take place during an interaction, and also specifies the format of the messages. A message format is defined through ‘message guidelines’ documentation, and an XML DTD (Document Type Definition) describing the syntactic structure a message should have.
Hence, in theory, all businesses have to do to set up a new partnership (involving the creation of a interaction protocol) is to agree on which PIPs to use, and implement the PIPs according to their specification. However, as different businesses can have different back-end processes, some flexibility within the standards is necessary to enable all businesses to satisfy it. For example, one business may normally represent dates on invoices using ISO 8601 format (YYYY-MM-DD) while another may use UK common practice (DD/MM/YYYY). One business may expect the account details of the buyer on an invoice, while another may not. To allow differences such as these, PIP definitions often make use of generic datatypes (such as strings or integers) and include optional fields or fields with unbounded cardinalities. As a result of this flexibility, there is no guarantee that two RosettaNet compliant companies will be able to communicate with each other: different business practices or back-end systems may impose different conditions on the presence of some information or on its format. Because of this, it is necessary to reconcile the different processes used by two companies which intend to interact via RosettaNet. There is some flexibility in the way in which a PIP can be implemented, and it is necessary that interacting parties agree as to the specific implementation chosen. This process of reconciliation is currently carried out off-line, using spreadsheets to document decisions. Developers then implement these decisions as they encode the PIPs. This can be a very time-consuming process, meaning that it can take many months to create a new RosettaNet partnership. Hence interoperability, one of the advantages of standardisation, is sacrificed in favour of flexibility.
RosettaNet are currently developing Next Generation PIPs (see RosettaNet Next Generation architecture at http://rosettanet.org/nextgenarchitecture) in an attempt to produce specifications than are more formal than the message guidelines used in the current standards. For each Next Generation PIP, RosettaNet specifies a UML (Unified Modelling Language) class diagram (see Object Management Group. Object Constraint Language Specification, Version 1.4, September 2001) and XML Schemas that replace the XML DTDs. The UML class diagram defines the business objects —such as financial documents or purchase requests—that are used in the PIP. To encourage reuse across PIPs, RosettaNet defines a domain model, i.e. a set of base classes that can be reused or subclassed in the UML class diagrams. The XML Schemas define what makes an XML document a syntactically valid PIP document. XML Schemas are defined manually from the UML class diagram.
Having an explicit machine-readable representation of the constraints imposed by a PIP makes setting up a partnership quicker and easier. Reconciliation can take place by agreeing a set of further constraints on each XML Schema within the PIP. Furthermore, having the agreed document structure specified in this format allows the developers to use tools such as Contivo (see http://www.contivo.com) to rapidly automate the process of document generation. However, this approach has several disadvantages:                The constraints that XML Schema are able to represent are mainly constraints on the syntax, not the semantics, of documents. This means certain constraints which appear in a PIP specification which cannot be represented in the XML Schema. A typical example of this sort of constraint is a dependency between fields, for instance the presence of a field implying a cardinality constraint on another field. RosettaNet uses OCL (Object Constraint Language) (see Object Management Group. Object Constraint Language Specification, Version 1.4, September 2001) to represent such constraints in the definition of Next Generation PIPs. These are documented as comments within the XML Schemas.        As seen earlier, a company's business processes impose constraints on the deployment of PIPs. Some of these constraints are of syntactic nature and can usually be captured in an XML Schema—which must be more specific than the PIP XML Schema. Some may be of semantic nature and so cannot be expressed in the XML Schema. Companies deploying RosettaNet PIPs usually document these semantic constraints in the form of spreadsheets that are manually created for the purpose of one deployment.        Additional constraints imposed during the reconciliation process may also be semantic in nature, and therefore cannot be represented in a machine-readable format.        The same business object class may appear in several documents exchanged during an interaction. Constraints imposed on this class should be applied to all documents that use this class (either directly or through a subclass). Currently, this will mean editing the entire associated schema to include the constraint. This imposes an unnecessary burden on the developers, and can potentially pose maintenance problems.        Constraints on a business object class depend on the context (i.e. the specific deployment scenario) in which this class is used.        
The Next Generation PIP cannot adequately manage the application of different constraints in different circumstances. Currently, the developers would have to manually aggregate the constraints corresponding to a deployment context into refined XML Schemas and other informal documents—when XML Schema is not expressive enough. This is inefficient and could pose maintenance problems. Moreover, since these constraints are not captured in a formal and systematic way, some knowledge could be lost from one deployment to the next.                The same constraint may apply to a certain class of partners. For instance, a back-end system could impose a constraint on a Tax class for all its European partners. Similarly, it should be possible to apply constraints on classes of PIP documents (e.g. invoicing documents) or business processes (e.g. Electronic component purchasing). However, this cannot be carried out without editing all of the associated schema to include the constraint, and as has been mentioned above this imposes an unnecessary burden on the developers, and can potentially pose maintenance problems.        
In Towards syntax-independent B2B by B. Hofreiter, C. Huemer, and W. Winiwarter, (ERCIM News, 51:25-26, October 2002) there is a recognition that many B2B vocabularies and interaction protocols are not interoperable because businesses use different subsets of the standards. The proposed solution of this prior art paper is to generate specific syntax (with XML Schema) out of a semantic layer (with RDF (Resource Description Framework) Schema) capturing business requirements. However, this solution does provide a solution which takes into consideration the compatibility of the solution with existing business partners' constraints. Furthermore the validation is still manually implemented.
Several solutions have already been proposed to bridge the gap between XML and RDF to provide rich semantic descriptions to XML applications. Some solutions are application specific—such as in ‘Combining RDF and XML Schemas to Enhance Interoperability Between Metadata Application profiles’, J. Hunter and C. Lagoze inProceedings 10th International World Wide Web Conference (WWW10), 2001 which uses a combination of XML Schema and RDF Schema. The lack of ability to generalise the solution means it has limited application to problems generally. Some others solutions are more general but disadvantageously require changes to XML or RDF.